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Abstract —Star Sensor, also known as star-tracker, is a high- 
accuracy 3-axis attitude sensor used onboard spacecrafts. It 
processes stars from a sky image captured using an area imaging 
detector (generally lk x lk pixels Charge Coupled Device) to 
generate attitude information. Its accuracy about the boresight is 
poorer than about the cross-axes. This is improved by using two 
sensor heads with staggered Fields-Of-View (FOVs) and three to 
avoid break during occultation of any head. All the sensor heads 
have identical processing operations. So, the Processing Unit (PU) 
is made common. This minimizes the system electronics, power 
consumption and also thermal dissipation on each CH, allowing 
more efficient cooling of CCD and improving sensor 
performance. The resulting multiple Camera Heads (CHs) are 
operated remotely by the common PU. Thus, a programmable 
Video Processor (VP) is designed for the CH as an efficient data 
acquisition co-processor to the PU. The VP works in parallel 
freeing PU for attitude computation from the data acquired from 
multiple CHs. VP acquires CCD images and pre-processes them 
to reduce data size, speeding up PU processing. It is 
programmable for different modes of operation based on full- 
frame star-search or Region-of-Interest (ROI) readout, thereby 
providing flexibility, while maintaining rigidity in 
implementation as required by CCD. Communication of the VP 
with the PU is configured via low-power high-speed SpaceWire 
link. The VP is implemented in a low-power FPGA. All 
instruction and data storage is on-chip. 

Keywords—Video Processor , CCD, Star Sensor , FPGA , FU, 
EU, RAM. 

I. Introduction 

A multi-head Star Sensor uses three Camera Heads (CHs) to 
improve the sensor boresight attitude accuracy. Using a single 
common Processing Unit (PU) reduces size and weight of the 
sensor, and also provides thermal advantages since the major 
heat dissipative elements, like the processor, memory and 
power electronics, are now in the PU. This greatly improves 
efficiency of the CCD cooling in the CH, achieving lower 
CCD temperature, reducing noise, and hence improving 
attitude accuracy of the sensor. The PU derives attitude 
information from stars available in the sky as imaged by the 
CCD of each CH. Image capture and readout from the CCD is 
sequential, processor-intensive and time-consuming. So, a 
dedicated Video-Processor [1] (VP) is designed as a co¬ 
processor to the PU in each CH. 


The VP is programmable by the PU and works independently 
in parallel to the PU to acquire CCD image data. This relieves 
the PU to process data from all three CHs for attitude 
computation, increasing the sensor update rate and accuracy. 
The VP can be programmed for different modes of operation 
and has features to optimize the CCD readout accordingly. It 
automatically detects stars on the fly, while acquiring the 
captured image in lost-in-space mode of the sensor and 
transfers only star data to the PU. This preprocessing 
significantly reduces the data transferred to and processed by 
the PU since stars occupy only a minute portion of the entire 
image. The VP also performs CCD signal conditioning and 
video offset estimation automatically. The VP is implemented 
in an FPGA and does not use any external memory, keeping 
power consumption to a minimum. In view of this, SpaceWire 
[3] communication is selected for data transfer between VP and 
PU. 

The functional requirements, design and implementation of 
the VP are discussed in the following sections. 

II. Video processor Operation 

A. Overview 

The VP is programmed by the PU for each frame of image 
data acquisition and then initiated at a synchronized time. The 
VP then sequentially executes the instructions, controls and 
sequences all the associated peripherals to acquire star image 
data from the CCD, pre-processes it and stores the data in a 
suitable format to be transferred back to the PU. In this way, 
the VP allows the PU to select suitable heads and schedule 
their operations as required without actually involving in the 
image readout sequence. The VP is designed to ensure 
execution of a single action at any given time since the CCD 
does not support parallel operations. This simplifies its design, 
which is a key requirement in any space system. 

B. Interfaces 

To acquire CCD image data, the VP must interface with 
and control a host of peripherals. It drives the vertical and 
horizontal readout clocks of the CCD [2] , performs signal offset 
correction by supplying appropriate input to a DAC, digitizes 
CCD video data by controlling ADC sampling and conversion 
operation and collects the digitized data. It pre-processes the 
acquired data before storing in internal RAM. The VP also 
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acquires health-keeping (HK) data, such as CCD temperature 
and supply voltages, using the ADC. Data is communicated to 
the PU through Space Wire. 


III. Video processor architecture 


The functions of the VP (Fig. 1) are implemented in two 
sections. The first section, the Video Acquisition section, 
consists of the Fetch Unit, Execute Unit and Transmit Buffer 
Write Unit. The second section, the communication section, 
consists of the SpaceWire Protocol, Transmit and Receive 
Buffers and the Bridge. 



Fig. 1. Block diagram of Video Processor 
A. Component description 

A brief description of the components involved is as 
follows. 

1) Fetch Unit (FU). It fetches instructions sequentially 
from internal RAM, decodes them and writes data to the 
relevant registers of Execute Unit. Instructions are formed as 
16-bit data words, where the first 4bits represent instruction 
opcode, and the following 12-bits represent data when 
applicable (Fig. 2) _ 


OPCODE 

Mnemonic 

Description 

0 

LinTr### 

Ld Line counter for line transfer 

1 

LinD### 

Ld Line counter for line dump 

2 

Flush ### 

Flush pixels 

3 

Read### 

Read pixels 

4 

LDIC ### 

Load Integration Counter 

5 

ModRg ### 

Set Mode Register for frame 

6 

LDTHD### 

Load Threshold Value 

7 

LDFSAR ### 

Load target value for float DAC 

calbratn 

8 

LDSDAC ### 

Load Video Signal DAC 

9 

LDRDAC ### 

Load Video Reset DAC 

A 

ConvHK 

Convert HK channels 

B 

LDWin ### 

Load window number 

C 

LDVSAR ### 

Load target value for vid DAC calbratn 

D 

NOP 

No Operation 

E 

LatchSST 

Latch the value of Star Sight timer 

F 

HLT 

HALT Execution 


Fig. 2. Instruction set, ### indicate d!2-bit data 


A “No Operation” instruction is also provided to program 
small delays in multiples of machine cycles(583.3ns). Initially, 
the FU waits to be initiated by a sync signal from the PU. It 
then continues fetching instructions from internal memory 
until it encounters a HALT instruction. The FU waits for the 
EU to complete execution of one instruction before fetching 
the next one. 

2) Execute Unit (EU): It acquires image data by driving 
CCD vertical and horizontal readout clocks in a phased and 
sequential manner. Mode (flush, bin, dump) and number of 
clocks generated are controlled by EU registers. Inputs to 
DAC and ADC are generated in synchronization to CCD 
readout. The VP dynamically corrects the variable offset in 
CCD output. The EU also implements a programmable 
Integration Counter to control CCD exposure time. It is also 
responsible for acquisition of HK data. The EU acquires the 
digitized image and HK data from the ADC, preprocesses it 
and passes the result to the Transmit Buffer Write Unit. 

3) Transmit Buffer Write Unit (TxBufWU): It receives data 
from the EU and writes it into the transmit buffer in a 
SpaceWire appropriate format. 

4) SpaceWire codec: SpaceWire is a bidirectional full- 
duplex serial communication protocol [3] . It is a low-power 
high-speed protocol operable at 2Mb/s to 400 Mb/s. 
SpaceWire has been used as a core in this design, and 
configured for link operation speed of 12 Mb/s. Data 
transmission is in a 10-bit format (8 bit data + 1 bit parity + 1 
bit control/data). The data communicated over this link is 
stored in the Receive and Transmit buffers via a Bridge. 

5) Receive and Transmit buffers: They are dual-buffered 
FIFOs implemented in on-chip RAM to store the PU 
instructions and CCD star image data respectively. They are 
accessible by the SpaceWire codec and the VP via the Bridge. 
Each buffer is 512 bytes in size and protected by error 
detection and correction (EDAC) logic against single event 
upsets on orbit. FIFO stores data for SpaceWire 
communication in 9-bit format (8 bit data + 1 bit control/data). 

6) Bridge : It forms the link between the SpaceWire core 
and video acquisition section. It provides necessary interface 
inputs to the SpaceWire codec for configuring the 
communication between CH and PU. It handles the error 
signals from SpaceWire and monitors its status. It also 
controls and co-ordinates access by the SpaceWire and VP to 
the dual buffered Receive and Transmit FIFOs. 

B. Design Features 

The VP includes a host of features to provide flexibility to 
the PU and to improve sensor performance, as described ahead: 

1) The VP acquires image data in two modes 

a) Acquisition Mode: Also known as lost-in-space mode, 
the VP reads out the entire CCD frame and preprocesses the 
image data to auto detect star like objects. A high pass filter is 
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designed using which the VP filters out low frequency data 
from the image. The high frequency data output from the filter 
is detected as star image. The VP stores location and intensity 
information of such objects and transmits it to the PU. This 
preprocessing reduces data transferred to PU by a factor of 
one hundred, reducing not only time taken for data 
communication but also time taken by PU for processing and 
also memory size requirement. CCD image readout time is 
reduced by programming VP to bin pixels with bin factor of 
up to three. 

b) Track Mode: In this mode, star locations are 
predicted by the PU and hence, the VP is operated in a 
Region-of-Interest (ROI) readout mode. It stores and transmits 
the intensity information corresponding to only the ROI 
pixels, commanded by PU. Thus, in track mode as well, data 
size is greatly reduced, improving communication time and 
PU processing speed. However, since CCD is a sequential 
access device, the remaining pixels are also to be transferred 
out to clean out the charges accumulated (flushing) These 
pixels are flushed out at a higher rate to reduce total readout 
time. 

2) Auto offset estimation: CCD video signal consists of 
three levels: reset, floating gate and video. Subtracting floating 
gate level from the video level gives true pixel intensity. So, 
both levels are sampled by ADC and subtracted within the EU. 
Clearly, to maximize the dynamic range of the video signal, it 
is desirable that floating gate level reads a minimum number 
of ADC counts. For this reason, a DAC is used for floating 
gate offset subtraction. However, floating gate level varies 
with temperature, meaning the optimum DAC offset value 
also varies. So, the VP performs auto offset estimation of the 
floating gate level to determine the required offset subtraction. 
The video level may also have an offset in case of background 
illumination. In this case, the star illumination is stored over 
and above the background intensity. Given the CCD signal is 
amplified before digitization, this also results in a loss of 
useful data range. So, the VP estimates the CCD signal video 
level offset as well to determine background illumination. This 
improves sensor performance. 

3) Dual Data buffering: The Receive and Transmit buffers 
are implemented as two buffers each. At any given time one 
set of FIFOs is made available to the Video Acquisition 
section and another to the SpaceWire codec. Receive and 
Transmit buffers are swapped at appropriate times 
independent of each other. The swapping is handled by the 
Bridge. The FIFOs are reset after they have been read. This is 
done to avoid error propagation. The Dual Buffering scheme 
allows image acquisition to be performed un-interrupted and 
in parallel to data communication. It also implicitly forms 
discrete data modules, which helps data error containment and 
recovery. 

4) Data encoding: The VP sends different kinds of data to 
the PU for processing such as star pixel location and intensity 
during auto-star detection, ROI pixel intensity, HK data, auto¬ 


offset estimation data and register data. As data transfer and 
instruction execution occur in parallel, the PU receives a 
continuous stream of data from the VP consisting of a mix of 
data types. To help PU in data clustering and data recognition, 
data is encoded as 16 bit words, where 12-bit data word is 
associated with an appropriate 4-bit identifier. This helps 
implement a continuous and parallel data transfer system. 

5) CCD Cooler control: The VP performs CCD cooler 
control operations as programmed by the PU. This is done to 
maintain CCD temperature for low noise performance. The 
VP acquires CCD temperature as part of HK and relays it to 
the PU. This forms a feedback system, regulating CCD 
temperature for consistent and high accuracy performance. 

The VP is designed to be programmable by the PU for the 
features of mode of operation, auto offset estimation and CCD 
cooler control. The remaining features are integral to the 
operation of the VP. 

IV. Implementation 

The VP design is coded in VHDF. The target device 
selected for this application is a radiation tolerant FPGA with 
250k gate density . The design utilizes 76% of the FPGA 
logic resources and 33% of the FPGA memory. It is tested by 
performing post-layout simulation. The VP is implemented in a 
practical test setup and its functionality is exercised. 

The following figure is a simulation waveform obtained 
using ModelSim. The VP design is interfaced with a testbench 
to simulate PU. The figure shows an established SpaceWire 
link and CCD clocks being generated for vertical and 
horizontal readout. (Fig. 3) 
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A practical test setup consisting of readout electronics 
interfaced with CCD is made. The VP FPGA is programmed 
and inserted into the test setup. The setup is operated from a 
console using Space Wire communication simulator. 
Commands for CCD image readout are issued from the console 
and waveforms are captured using a CRO. 


The following figure shows horizontal clocks to the CCD in 
flush and readout modes respectively. (Fig. 4) 
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Fig. 4. Flush and Normal readout clocks to CCD 


The following waveforms show CCD readout clock 
generation with 2 pixel binning and resultant CCD video 
output. The reset, floating and two video levels (resulting from 
two pixels getting binned) of the CCD video signal are visible. 
(Fig. 5) 



Fig. 5. Binned CCD output 


The CCD is exposed to a star scene simulation and a full 
frame image is acquired. The VP is configured to readout the 
CCD data with a binning factor of two. The captured image is 
displayed using MATLAB. Two axes correspond to line and 
pixel numbers and the third axis to pixel intensity recorded. 
The peaks shown in the figure correspond to stars simulated in 
the scene. (Fig. 6) 



Fig. 6. PSF of captured star image 

V. Conclusion 

The multi-head configuration for star sensor is used to 
improve its boresight accuracy. The Video Processor (VP) 
housed in each Camera Head (CH) is programmable by the 
common Processing Unit (PU) to acquire sky images. It then 
extracts star data and provides it to the PU for attitude 
computation. The PU and VP work in parallel, thereby 
improving the update rate of the sensor. The VP drives CCD in 
a phased manner to clock out image signal. The image signal is 
acquired by VP by controlling the data acquisition hardware. 
The VP performs dynamic signal conditioning to improve 
sensor performance. It preprocesses the acquired raw image 
data to auto-detect stars, and stores only relevant data. This 
drastically reduces data size by a factor of one hundred. The 
advantages of this can be seen in the reduced data transfer time 
as well as processing load on the PU. Communication between 
the PU and VP is via low-power, high-speed SpaceWire 
communication link. All data storage is on-chip, ensuring 
minimal power requirements. 

The VP has been implemented in an FPGA and tested 
successfully in a practical test setup. Having proven an 
efficient data acquisition system, it is selected for usage in 
flight Star Sensor systems of ISRO. 
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